Systems and methods for distributed ledger archiving and size management

ABSTRACT

A system described herein may generate a group of distributed ledgers that are each associated with a respective set of ledger parameters, receive a data item that is associated with a set of attributes, identify a distributed ledger that is associated with ledger parameters that meet the set of attributes, and record the data item to the distributed ledger that is associated with ledger parameters that meet the particular set of attributes. The system may determine that a set of archival parameters, associated with a particular distributed ledger, have been met; and may remove the particular distributed ledger from the group of distributed ledgers based on determining that the set of archival parameters, associated with the particular distributed ledger, have been met. Nodes that maintain the group of distributed ledgers may remove ledger data, associated with the removed distributed ledger, from one or more storage resources associated with the nodes.

BACKGROUND

Distributed ledgers, such as blockchains, provide for the decentralizedand secure storage of data. Distributed ledgers may further provide forthe immutability of recorded data, as data may not be altered oncerecorded to a distributed ledger. Organizations or other entities maystore relatively large amounts of data, such as operational data, userdata, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example creation of one or more distributedledgers that are associated with different ledger parameters and/orarchival parameters, in accordance with some embodiments;

FIG. 2 illustrates the recordation of data to one or more ledgers basedon attributes of the data and the ledger parameters associated with theone or more ledgers, in accordance with some embodiments;

FIG. 3 illustrates an example creation of one or more distributedledgers based on determining that a set of ledger parameters have beenmet, in accordance with some embodiments;

FIGS. 4 and 5 illustrate examples of the removal of a distributed ledgerbased on determining that a corresponding set of archival parametershave been met, in accordance with some embodiments;

FIG. 6 illustrates example queries that may be performed with respect toone or more distributed ledgers, in accordance with some embodiments;

FIG. 7 illustrates an example of management instances, in accordancewith some embodiments;

FIG. 8 illustrates an example process for managing the size of one ormore distributed ledger groups, in accordance with some embodiments;

FIG. 9 illustrates an example environment in which one or moreembodiments, described herein, may be implemented;

FIG. 10 illustrates an example arrangement of a radio access network(“RAN”), in accordance with some embodiments; and

FIG. 11 illustrates example components of one or more devices, inaccordance with one or more embodiments described herein.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements.

Distributed ledgers, such as blockchains, may provide for adecentralized, immutable mechanism by which data may be recorded and/orretrieved. The immutability of distributed ledgers (referred to hereinsimply as “ledgers”) may cause such ledgers to grow in sizeindefinitely. Nodes, validators, or other participants of such ledgersmay accordingly have ever-increasing storage resource demands in orderto securely maintain and/or otherwise participate in the maintenance orprovenance of such ledgers. In some situations, maintaining such ledgersmay be unnecessary, such as where the data stored in the ledger has novalue after a period of time.

Embodiments described herein provide for a reduced amount of storageresources required to maintain data using ledger techniques, such asblockchain techniques. As discussed herein, for example, differentledgers, blockchains, channels, etc. may be associated with differentledger attributes. Ledger attributes may specify criteria, conditions,etc., where data to be recorded using ledger techniques may be recordedto a particular ledger that is associated with criteria, conditions,etc. that are met by the data. For example, ledger attributes mayspecify a particular time window, such as a particular month, aparticular year, etc., and data that has a creation date (or othersuitable reference date) that falls within a time window associated witha particular ledger may be recorded to that particular ledger. Asfurther discussed herein, each ledger may be associated with a set ofarchival parameters, based on which the ledger may be removed, deleted,archived, etc. For example, a particular ledger may be associated with aset of archival parameters that specify a date on which the particularledger should be deleted.

In this manner, ledgers that have become “stale” or that store old datathat is unlikely to be accessed may be removed, without impacting theimmutability and trust associated with other ledgers (e.g., newerledgers that store “fresh” data or newer data that is more likely to beaccessed). The removal of the ledgers for which archival parameters havebeen met (e.g., ledgers associated with “stale” or old data) may free upstorage resources of nodes, validators, and/or other participants of theledger, which maintain and/or provide the ledger.

As shown in FIG. 1 , for example, two or more nodes 101 (e.g., nodes101-1 and 101-2) may register (at 102) as nodes associated with LedgerManagement System (“LMS”) 103. LMS 103 may be or may include a ledgerframework (e.g., the Hyperledger framework), a decentralized application(“dApp”), or other device or system that is able to create one or moreledgers, delete one or more ledgers, interact with one or more ledgers(e.g., record data to such ledgers), deploy smart contracts to one ormore ledgers, access one or more ledgers (e.g., read, explore, crawl,etc. such ledgers), serve as an interface between one or more nodes orclients (e.g., clients associated with nodes 101 and/or other clients)and one or more ledgers, register nodes or clients, and/or perform othersuitable functions. For example, LMS 103 may generate, provide, and/orvalidate one or more clients, addresses, wallets, private keys, etc.associated with nodes 101-1 and 101-2. As such, nodes 101-1 and 101-2may be or may include nodes, validators, peers, etc. with respect to oneor more ledgers created by LMS 103, as discussed herein. For example,nodes 101-1 and 101-2 may participate in a consensus mechanism in whichledger operations, such as the creation of a ledger, the removal of aledger, the recordation of data to a ledger, etc. is validated, signed,etc. by nodes 101-1 and 101-2.

As further shown, nodes 101-1 and/or 101-2 may provide (at 102) a set ofledger parameters and/or archival parameters. For example, node 101-1and/or node 101-2 may provide such parameters to LMS 103 (e.g., via anapplication programming interface (“API”), a dApp, a web portal, orother suitable type of communication pathway), and such parameters maybe validated by nodes associated with LMS 103 (e.g., nodes 101-1, 101-2,and/or one or more other nodes). Additionally, or alternatively, someother device or system may provide the parameters to LMS 103, and suchparameters may be validated by nodes associated with LMS 103 prior toimplementation of the parameters as described herein.

As discussed above, ledger parameters may specify conditions, criteria,etc. that may be associated with particular ledgers created by LMS 103and ultimately maintained by nodes 101. In the examples describedherein, a first set of ledger parameters may specify a monthly interval,based on which a first ledger may be associated with a particular month,a second ledger may be associated with the next month, a third ledgermay be associated with month after the next month, etc. Further in theexamples described herein, a second set of ledger parameters may specifyone or more flags or indicators, such as an “important” flag. Asdiscussed below, LMS 103 may receive data to be recorded to one or moreledgers, identify attributes of the data to be recorded, and record suchdata to one or more appropriate ledgers (e.g., one or more ledgersassociated with ledger parameters that are met by the attributes of thedata). In practice, other types of ledger parameters may be specifiedbased on any suitable type of conditions, criteria, etc.

The ledger parameters may also be used by LMS 103 to determine when togenerate a new ledger that is associated with a particular set of ledgerparameters. For example, assume that the ledger parameters (provided at102) specify a monthly interval. LMS 103 may determine (at 104) that anew month has begun (e.g., at 12:01 AM on Jan. 1, 2022). LMS 103 mayaccordingly determine that a new ledger should be created, where such isassociated with the month of January 2022. As such, LMS 103 may create(at 106) ledger 105-1, which is associated with the month of January2022. In the examples discussed herein, data to be recorded to one ormore ledgers 105 may be “associated with” a given date if such date isspecified in the data, such as a creation date associated with the data.In some embodiments, the date may be indicated or associated with suchdata in some other manner, such as a “last modified” date, a “receivedon” date, or some other suitable date. As further shown, ledger 105-1may be associated with archival parameters indicating that ledger 105-1should be removed after one year (e.g., on or about Jan. 1, 2023).

As further shown in this example, LMS 103 may also generate (at 106)ledger 105-2, which is associated with data that includes an “important”flag. For example, as discussed herein, data that includes the“important” flag and is received by LMS 103 for recordation to one ormore ledgers 105, may be recorded to ledger 105-2. In this example, thearchival parameters for ledger 105-2 may specify that ledger 105-2should never be removed, or ledger 105-2 may not be associated with aset of archival parameters.

As shown in FIG. 2 , LMS 103 may receive (at 208) a particular data itemD1 for recordation to one or more ledgers. For example, LMS 103 mayreceive data item D1 from node 101-1. In some embodiments, LMS 103 mayreceive data item D1 from some other node or client that is authorizedto provide data for recordation to one or more ledgers 105 (e.g., a nodeor client that has registered with LMS 103). In this example, data itemD1 has a creation date of January 2022, which may be specified in thedata itself, may be provided as metadata, or may otherwise be indicatedin conjunction with the providing of the data.

LMS 103 may also receive (at 210) data item D2 for recordation to one ormore ledgers, such as from node 101-2 and/or some other source (e.g.,another node, client, etc.). Data item D2 may also have a January 2022creation date. Data item D2 may also be associated with an “important”flag, which may be specified in header information associated with dataitem D2, metadata associated with data item D2, and/or as a “body” orpayload of data item D2.

LMS 103 may identify (at 212) attributes of data items D1 and D2. Forexample, in some embodiments, LMS 103 may analyze metadata associatedwith the provided data items, may analyze header information associatedwith the provided data items, and/or may analyze payload information orcontent of the data items themselves in order to identify attributes ofthe data items (e.g., the January 2022 creation date of data items D1and D2, as well as the “important” flag associated with data item D2 inthis example).

Based on identifying the attributes of data items D1 and D2, LMS 103 mayrecord the data items to one or more ledgers 105. For example, LMS 103may record (at 214) data items D1 and D2 to ledger 105-1, based on theledger parameters associated with ledger 105-1 indicating that ledger105-1 is associated with data items with a January 2022 creation dateand further based on determining that attributes of data items D1 and D2indicate that these data items are associated with a January 2022creation date. LMS 103 may also record (at 216) data item D2 to ledger105-2, based on the ledger parameters associated with ledger 105-2indicating that ledger 105-2 is associated with data items with an“important” flag and further based on determining that attributes ofdata item D2 indicate that data item D2 is associated with the“important” flag. In other words, data item D2 may be recorded to bothledgers 105-1 and 105-2 in this example. As discussed below, therecordation of the same data item to multiple ledgers 105 may be usefulin situations where a particular one of the ledgers 105 is deleted(e.g., due to becoming “stale,” old, or otherwise meeting one or moreconditions specified by archival parameters), but where the data itemmay still have some relevance or other measure of desirability beyondother data items recorded to the particular ledger 105.

As shown in FIG. 3 , LMS 103 may automatically create one or moreledgers 105 based on identifying that ledger parameters (e.g., asprovided at 102 by one or more nodes 101 and/or other sources) are met.For example, at the beginning of February 2022 (e.g., one month afterthe creation of ledger 105-1, associated with data items with a January2022 creation date), LMS 103 may determine (at 302) that a new ledgershould be generated in order to maintain data items with a February 2022creation date. In some embodiments, the ledger parameters (e.g., asspecified at 102) may explicitly include triggers based on which aseries of ledgers should be created (e.g., at the beginning of everymonth, at the beginning of every year, etc.).

In some embodiments, when such series are specified by ledgerparameters, a next ledger in the series may reference a previous ledgerin the series, and/or the previous ledger in the series may referencethe next ledger in the series. For example, in the example of FIG. 3 ,ledger 105-3 (e.g., associated with February 2022 data items) mayinclude a reference to ledger 105-1 (e.g., associated with January 2022data items), such as a hash, Merkle proof, or some other representationof some or all of the data stored in ledger 105-1. In some embodiments,the reference to ledger 105-1 may include an identifier, name, or otherreference to ledger 105-1 (e.g., as maintained by Ledger ManagementSystem 103). Additionally, or alternatively, ledger 105-1 may include areference to ledger 105-3, such as an identifier, name, etc. of ledger105-3. Such indications may indicate, for example, that ledgers 105-1and 105-3 are associated with a series of ledgers, and that 105-1 is aledger that immediately precedes ledger 105-3 in the series (and/or thatledger 105-3 immediately follows ledger 105-1 in the series).

In some embodiments, LMS 103 may identify conditions under which ledgerparameters are inapplicable and/or under which ledger parameters may beapplicable, and may automatically generate ledgers based on identifyingthat ledger parameters have become potentially applicable. For example,during the month of January 2022, LMS 103 may determine that no dataitems with a creation date of February 2022 will be received (e.g.,based on the logical impossibility of receiving data items created inthe future), and may forgo creating a ledger to record data items with acreation date of February 2022. On the other hand, once February 2022begins, LMS 103 may determine that it is possible to receive data itemswith a creation date of February 2022, and may accordingly generate (at304) ledger 105-3, with ledger parameters indicating that ledger 105-3stores records associated with data items with a February 2022 creationdate.

In some embodiments, LMS 103 may forgo creating a ledger (such as ledger105-3) until actually receiving a data item matching a particular set ofledger parameters. For example, in some embodiments, LMS 103 maygenerate (at 304) ledger 105-3 after receiving a data item, with acreation date of February 2022, for recordation to one or more ledgers.

Once ledger 105-3 is generated (at 304), LMS 103 may maintain ledgers105-1, 105-2, and 105-3. For example, LMS 103 may maintain informationindicating that ledgers 105-1, 105-2, and 105-3 are active, established,or should otherwise be maintained by nodes that have registered with LMS103, such as nodes 101-1 and 101-2. For example, registered nodes (suchas nodes 101-1 and 101-2) may be “subscribed” to one or more channels,may receive a notification from LMS 103, and/or may otherwise receive anindication that ledger 105-3 has been generated. Accordingly, suchregistered nodes may maintain a copy of ledger 105-3 (e.g., in additionto ledgers 105-1 and 105-2), may participate in consensus mechanismsassociated with ledgers 105-1, 105-2, and 105-3, and/or may performother functions to maintain the provenance of ledgers 105-1, 105-2, and105-3.

Over the course of time, LMS 103 may continue to generate additionalledgers 105 in a manner similar to that described above with respect toFIG. 3 . For example, as shown in FIG. 4 , LMS 103 may have additionallygenerated ledgers 105-4 through 105-14, which may each be associatedwith a particular month (e.g., March 2022, April 2022, etc.). That is,as of January 2023 (e.g., as depicted in FIG. 4 ), LMS 103 may havegenerated a monthly ledger for each month that has elapsed, inaccordance with ledger parameters provided (at 102) by one or moresuitable sources.

Further, LMS 103 may determine (at 402) that archival parametersassociated with ledger 105-1 have been met. For example, as discussedabove, ledger 105-1 (as well as ledgers 105-3 through 105-14) may beassociated with archival parameters indicating that such ledgers 105should be removed after one year (e.g., ledger 105-1 which is associatedwith January 2022 data items should be removed in January 2023, ledger105-3 which is associated with February 2022 data items should beremoved in February 2023, and so on).

Based on determining that the archival parameters associated with ledger105-1 have been met, LMS 103 may remove (at 404) ledger 105-1. Forexample, LMS 103 may remove ledger 105-1 from an index or master list ofledgers associated with nodes 101-1 and 101-2 (and/or other nodes,clients, etc. that are subscribed to or are otherwise associated withone or more channels associated with ledgers 105-1 through 105-14).Additionally, or alternatively, LMS 103 may output a notification tonodes 101-1 and 101-2, and/or nodes 101-1 and 101-2 may otherwisedetermine that ledger 105-1 has been removed.

For example, as shown in FIG. 5 , LMS 103 may output (at 506) anindication of the removal (at 404) of ledger 105-1 to nodes 101-1 and101-2. Additionally, or alternatively, as discussed above, nodes 101-1and 101-2 may otherwise determine that ledger 105-1 has been removed. Insome embodiments, LMS 103 may generate a new peer, channel, etc.associated with non-removed ledgers 105-2 through 105-14, and mayprovide such new peer, channel, etc. to nodes 101-1 and 101-2, which mayeffectively remove ledger 105-1.

Based on the removal of ledger 105-1, node 101-1, node 101-2, and/or oneor more other devices or systems may perform one or more “off-chain”operations (e.g., operations that do not include modifying orinteracting with ledgers 105 and/or LMS 103). For example, node 101-1may maintain information in off-chain repository 501 that is referencedby or is otherwise associated with data items stored in one or moreledgers 105. As one example, the data items stored in ledgers 105 mayinclude indexes, identifiers, pointers, Uniform Resource Locators(“URLs”), etc., that may reference video content, audio content,encrypted records, hash values, and/or other data stored in off-chainrepository 501. In this manner, the size of data stored in off-chainrepository 501 (e.g., as referenced by data items recorded to ledgers105) may be magnitudes larger than the size of the data items recordedto ledgers 105.

When ledger 105-1 is removed, node 101-1 may remove, archive, etc. (at508) data referenced by records in ledger 105-1. For example, node 101-1may delete video content, audio content, and/or other data stored inoff-chain repository 501 that is referenced by records in ledger 105-1(e.g., where such records include pointers, links, etc. to such data).Node 101-1 may, for example, analyze ledger 105-1 to identify suchpointers, links, etc. included in ledger 105-1, and may remove thereferenced data from off-chain repository 501 on the basis of suchpointers, links, etc.

In some embodiments, node 101-1 may refrain from removing data stored byoff-chain repository 501 that is referenced in both a removed ledger andone or more ledgers that are not removed. For example, as discussedabove and as shown in FIG. 4 , the same data item D2 may be recorded toledgers 105-1 and 105-2. Assuming that this data item D2 references datastored in off-chain repository 501, node 101-1 may refrain from removing(at 508) the data referenced by data item D2 from off-chain repository501, based on data item D2 remaining in ledger 105-2 after ledger 105-1(which also references such data stored in off-chain repository 501) isremoved.

In some embodiments, removing, archiving, etc. (at 508) the off-chaindata may include erasing files or other data stored by one or morestorage devices associated with off-chain repository 501. As such,storage resources of off-chain repository 501, which were allocated tostoring the off-chain data, may be made available for use, thus reducingthe consumption of such storage resources. In some embodiments,archiving (at 508) the off-chain data may include compressing theoff-chain data using one or more suitable data compression techniques(e.g., according to one or more codecs), moving the data to a differenttype of storage medium (e.g., from a flash memory device to a platter ortape-based storage drive), moving the data to a different storage system(e.g., from an on-site system to a cloud-based system), etc.

As further shown in FIG. 5 , node 101-1 may include and/or may becommunicatively coupled to ledger repository 503-1, which may maintaininformation related to serving as a node associated with LMS 103. Suchinformation may include, for example, copies of ledgers 105 and/or otherdata associated with ledgers 105. Similarly, node 101-2 may maintainand/or may be communicatively coupled to ledger repository 503-2, whichmay also maintain information related to serving as a node associatedwith LMS 103. Based on receiving (at 506) the indication of the removalof ledger 105-1, nodes 101-1 and 101-2 may remove (at 510 and 512)ledger data associated with ledger 105-1. As such, storage resourcesassociated with ledger repositories 503-1 and 503-2 may be freed up,thus conserving the storage resources of ledger repositories 503-1 and503-2.

As other ledgers 105 are still maintained (e.g., ledgers 105-2 through105-14), information that is stored in the other ledgers may be able tobe retrieved or otherwise accessed. For example, as shown in FIG. 6 ,LMS 103 may respond to queries (e.g., from client 601 or some otherdevice or system that has registered with LMS 103 and/or is otherwiseauthorized to provide queries to LMS 103) with information stored in oneor more ledgers 105. For example, LMS 103 may receive (at 602) a firstquery from client 601. LMS 103 may obtain (at 604) one or more resultsbased on the first query. For example, LMS 103 may search recordsassociated with one or more maintained ledgers 105-2 through 105-14.That is, in situations where one or more ledgers were previously removedin accordance with embodiments described above (e.g., the exampleremoval of ledger 105-1), the obtaining (at 604) of the results may notinclude a search of the ledger 105-1.

In some embodiments, LMS 103 or some other device or system may maintain“world state” information based on information stored in some or all ofledgers 105-2 through 105-14. For example, LMS 103 may maintain a “flat”database or other type of data structure based on some or all of theinformation stored in ledgers 105-2 through 105-14. In instances wheredifferent values for the same attribute, label, etc. is different, theworld state may include a particular value for the particular attribute,label, etc. that is the most up-to-date value and/or is precedentialover the other values based on one or more other factors. When searchingfor results based on queries, LMS 103 may search the world stateinformation in lieu of, or in addition to, searching through individualledgers 105.

In some embodiments, the world state may indicate one or more ledgers105 from which one or more values for a particular attribute, label,etc. were obtained. In this manner, the source of the information in theworld state may be traceable to source data, including changes to suchvalues. In instances where a particular ledger 105 that is the source ofinformation in the world state is removed, the indication of such ledger105 may be used to investigate or otherwise identify the deleted data(e.g., using off-chain techniques).

In some embodiments, LMS 103 may perform a “pre-computation” or“pre-processing” operation to determine which ledger(s) to search basedon the query. For example, LMS 103 may analyze the query to determineone or more attributes that match or are otherwise associated with oneor more ledger parameters. For example, LMS 103 may determine that thequery indicates a date filter, requesting data items associated with acreation date of February 2022. In this situation, LMS 103 may searchledger 105-3 (e.g., associated with February 2022 data items) withoutsearching ledgers 105-4 through 105-14 (e.g., associated with March 2022through January 2023 data items). In this situation, LMS 103 may furthersearch ledger 105-2 (e.g., associated with data items with an“important” flag), as ledger 105-2 may not be associated with data itemswith a particular creation date restriction. That is, based on theledger parameters of ledger 105-2, ledger 105-2 may potentially includerecords pertaining to data items that were created in February 2022, asspecified by the date filter associated with the query.

Further assume that LMS 103 receives (at 608) a second query from client601 and/or from some other source. Assume that this second queryincludes a date filter specifying data items with a January 2022creation date. LMS 103 may determine (at 610) that this second query isassociated with a ledger that was removed (e.g., ledger 105-1). Forexample, since ledger 105-1 was removed and was associated with dataitems with a January 2022 creation date, LMS 103 may determine (at 610)that the second query is associated with removed ledger 105-1. LMS 103may accordingly forgo searching some or all of ledgers 105-2 through105-14 based on determining that the second query is associated withremoved ledger 105-1. Additionally, or alternatively, LMS 103 may searchledger 105-2 (e.g., which does not have restrictions on creation dates),but may forgo searching ledgers 105-3 through 105-14, which areassociated with creation dates that would not satisfy the filterindicated in the second query.

Forgoing performing (at 610) the search of one or more ledgers 105 mayconserve processing resources, time, or other resources associated withLMS 103. For example, LMS 103 may be able to determine that the resultis not available in ledgers 105-2 through 105-14 (or 105-3 through105-14) without performing an actual search of such ledgers 105. Thatis, based on attributes of the second query and based on ledgerparameters associated with ledgers 105, LMS 103 may be able to determinethat such ledgers 105 do not include records that may satisfy the query.

LMS 103 may indicate (at 612) that no result was found based on thesecond query. For example, LMS 103 may have found no results based onnot performing any searches of remaining ledgers 105. Additionally, oralternatively, LMS 103 may have searched one or more remaining ledgers105 but not all remaining ledgers 105 (e.g., may have searched ledger105-2 associated with “important” data items but not ledgers 105-3through 105-14 associated with respective time windows), and may havefound no results. In some embodiments, LMS 103 may indicate (at 612)that the query is associated with one or more attributes that meetledger parameters of one or more ledgers that were removed. For example,LMS 103 may indicate that records associated with the creation datefilter specified in the second query were removed. A requestorassociated with the query may be able to identify or infer that the lackof results may be due to the deletion of such records, and may notnecessarily affirmatively indicate that the result does not exist. Insuch a circumstance, the requestor may be able to communicate with oneor more external devices or systems (e.g., via off-chain communications)to potentially obtain results to the second query.

Examples discussed above are provided in the context of a particular setof ledgers 105 that are maintained by a particular set of nodes 101, andthat are generated or removed based on a particular set of ledgerparameters and/or archival parameters. In some embodiments, as shown inFIG. 7 , LMS 103 may maintain (at 702) multiple management instances701, where each management instance 701 includes a particular node group703, set of management parameters 705, and ledger group 707.

When registering with LMS 103, each node 101 may register as beingassociated with a particular management instance 701, and/or LMS 103 mayotherwise determine a particular management instance 701 associated witheach node 101. For example, nodes 101 that are associated with differentgroups, categories, organizations, etc. may be associated with differentmanagement instances 701. In this manner, different nodes 101 may haveaccess to different ledgers 105, without having access to other ledgers105. As such, management instances 701 may each be isolated or“sandboxed” with respect to each other.

A first management instance 701-1 may include a first node group 703-1,which may include a particular set of nodes 101. Management parameters705-1, associated with management instance 701-1, may have beenprovided, validated, signed, etc. by nodes 101 of node group 703-1. Asdiscussed above, management parameters 705-1 may include ledgerparameters 709-1 and archival parameters 711-1, which may indicateparameters related to ledger creation, ledger maintenance (e.g.,criteria based on which particular data items should be recorded tocertain ledgers 105), and/or ledger removal. Ledger group 707-1 mayinclude a set of ledgers 105 that were created based on managementparameters 705-1. For example, ledgers 105 of ledger group 707-1 mayinclude ledgers created based on ledger parameters 709-1, and that havenot been removed based on archival parameters 711-1.

Similarly, management instance 701-1 may include an association betweennode group 703-2, management parameter 705-1 (which may include ledgerparameters 709-2 and 711-2), and ledger group 707-2. LMS 103 may furthermaintain additional management instances 701, such as managementinstances 701-3 through 701-N, which may be independent and/or otherwisenot “aware” of each other's existence.

FIG. 8 illustrates an example process 800 for managing the size of oneor more ledger groups, in accordance with some embodiments. In someembodiments, some or all of process 800 may be performed by LMS 103. Insome embodiments, one or more other devices may perform some or all ofprocess 800 in concert with, and/or in lieu of, LMS 103, such as one ormore nodes 101 or other devices or systems.

As shown, process 800 may include generating (at 802) a group of ledgersassociated with respective ledger parameters and archival parameters.For example, as discussed above, LMS 103 may receive ledger parameters709 and archival parameters 711 from nodes 101 (e.g., a set of nodes 101of a particular node group 703 associated with a particular managementinstance 701), and/or may receive consensus, validation, etc. of suchparameters 709 and 711 from nodes 101. LMS 103 may receive suchparameters 709 and 711 on an ongoing basis, and may maintain distinctsets of parameters 709 and 711 for different management instances 701.

As discussed above, ledger parameters 709 may include conditions,attributes, parameters, etc. based on which one or more ledgers 105 maybe generated (e.g., automatically based on such parameters being met),and/or based on which data may be recorded to such ledgers 105. In someembodiments, ledger parameters 709 may include temporal parameters, suchas an indication of one or more times or time windows with which a givenledger 105 is associated. In some embodiments, ledger parameters 709 mayinclude other types of parameters other than temporal parameters, suchas keywords, labels, categories, etc. As also discussed above, archivalparameters 711 may include conditions, attributes, parameters, etc.based on which one or more ledgers 105 may be removed from the group 707of ledgers. For example, archival parameters 711 may specify a rollingtime window which, when attributes of a particular ledger 105 includetemporal information that falls outside of the rolling time window(e.g., where the ledger 105 may have become old, “stale,” aged, etc.),the particular ledger 105 should be removed. Additionally, oralternatively, archival parameters 711 may specify one or more times,dates, etc. at which ledgers 105 that include temporal information thatfalls within the one or more dates, times, etc. are removed from ledgergroup 707. For example, archival parameters 711 may specify or indicatetimes at which such ledgers 105 have become old, “stale,” etc. In someembodiments, archival parameters 711 may include conditions that are nottemporal in nature, such as conditions that are met or triggered basedon radio frequency (“RF”) conditions of a wireless network, load metricsassociated with a RAN of a wireless network (e.g., quantity of connectedUEs or other load metrics), the occurrence of a particular event, theoutput of an artificial intelligence/machine learning (“AI/ML”) model,or other suitable triggers.

Process 800 may further include receiving (at 804) a data item with aparticular set of attributes. For example, LMS 103 may receive, from arespective node 101 and/or other suitable source, a data item forrecordation to the group 707 of ledgers. The attributes may include ormay be based on metadata, header information, payload information or abody of the data item, or other suitable attributes. In someembodiments, the attributes may include temporal attributes, such as anindication of a particular date or time. Such particular date or timemay be, for example, a creation date associated with the data item, amodification date associated with the data item, a date of an occurrenceas indicated by the data item, or other suitable temporal information.In some embodiments, the attributes of the data item may include someother type of attributes, such as flags, identifiers, indicators,labels, etc.

Process 800 may additionally include identifying (at 806) one or moreledgers 105 of ledger group 707 that meet the particular set ofattributes. For example, LMS 103 may identify a particular ledger 105that is associated with temporal attributes that match temporalattributes of the data item, where such “match” may occur based on atime associated with the data item falling within a time windowassociated with the temporal attributes of ledger 105. In someembodiments, LMS 103 may identify a particular ledger 105 that isassociated with other attributes (e.g., other than temporal attributes)that match particular attributes of the data item, where such “match”may occur based on an exact match of such attributes, or based on ameasure of similarity of such attributes exceeding a threshold measureof similarity. Process 800 may also include recording (at 808) the dataitem to the identified ledger or ledgers 105.

Process 800 may further include determining (at 810) that archivalparameters 711 associated with a particular ledger 105 have been met.For example, in the example of temporal parameters, LMS 103 maydetermine that the particular ledger 105 has aged beyond a threshold agebased on archival parameters 711, may determine that a date or timewindow associated with the particular ledger 105 falls within a timewindow specified by archival parameters 711 as being associated withledger removal, and/or may otherwise determine that the temporalarchival parameters 711 have been met.

Process 800 may additionally include removing (at 812) the particularledger 105 from ledger group 707 based on determining that archivalparameters 711 associated with the particular ledger 105 have been met.For example, LMS 103 may remove a reference to the particular ledger 105from an index of ledgers 105 associated with ledger group 707, maynotify nodes 101 that maintain ledgers 105 of ledger group 707 that theparticular ledger 105 has been removed, and/or may perform othersuitable operations to remove the particular ledger 105. Nodes 101 mayaccordingly free up storage resources used to maintain the particularledger 105, and/or may free up storage resources used to maintainoff-chain data referenced by the particular ledger 105.

FIG. 9 illustrates an example environment 900, in which one or moreembodiments may be implemented. In some embodiments, environment 900 maycorrespond to a Fifth Generation (“5G”) network, and/or may includeelements of a 5G network. In some embodiments, environment 900 maycorrespond to a 5G Non-Standalone (“NSA”) architecture, in which a 5Gradio access technology (“RAT”) may be used in conjunction with one ormore other RATs (e.g., a Long-Term Evolution (“LTE”) RAT), and/or inwhich elements of a 5G core network may be implemented by, may becommunicatively coupled with, and/or may include elements of anothertype of core network (e.g., an evolved packet core (“EPC”)). As shown,environment 900 may include UE 901, RAN 910 (which may include one ormore Next Generation Node Bs (“gNBs”) 911), RAN 912 (which may includeone or more evolved Node Bs (“eNBs”) 913), and various network functionssuch as Access and Mobility Management Function (“AMF”) 915, MobilityManagement Entity (“MME”) 916, Serving Gateway (“SGW”) 917, SessionManagement Function (“SMF”)/Packet Data Network (“PDN”) Gateway(“PGW”)-Control plane function (“PGW-C”) 920, Policy Control Function(“PCF”)/Policy Charging and Rules Function (“PCRF”) 925, ApplicationFunction (“AF”) 930, User Plane Function (“UPF”)/PGW-User plane function(“PGW-U”) 935, Home Subscriber Server (“HSS”)/Unified Data Management(“UDM”) 940, and Authentication Server Function (“AUSF”) 945.Environment 900 may also include one or more networks, such as DataNetwork (“DN”) 950. Environment 900 may include one or more additionaldevices or systems communicatively coupled to one or more networks(e.g., DN 950), such as LMS 103.

The example shown in FIG. 9 illustrates one instance of each networkcomponent or function (e.g., one instance of SMF/PGW-C 920, PCF/PCRF925, UPF/PGW-U 935, HSS/UDM 940, and/or AUSF 945). In practice,environment 900 may include multiple instances of such components orfunctions. For example, in some embodiments, environment 900 may includemultiple “slices” of a core network, where each slice includes adiscrete set of network functions (e.g., one slice may include a firstinstance of SMF/PGW-C 920, PCF/PCRF 925, UPF/PGW-U 935, HSS/UDM 940,and/or AUSF 945, while another slice may include a second instance ofSMF/PGW-C 920, PCF/PCRF 925, UPF/PGW-U 935, HSS/UDM 940, and/or AUSF945). The different slices may provide differentiated levels of service,such as service in accordance with different Quality of Service (“QoS”)parameters.

The quantity of devices and/or networks, illustrated in FIG. 9 , isprovided for explanatory purposes only. In practice, environment 900 mayinclude additional devices and/or networks, fewer devices and/ornetworks, different devices and/or networks, or differently arrangeddevices and/or networks than illustrated in FIG. 9 . For example, whilenot shown, environment 900 may include devices that facilitate or enablecommunication between various components shown in environment 900, suchas routers, modems, gateways, switches, hubs, etc. Alternatively, oradditionally, one or more of the devices of environment 900 may performone or more network functions described as being performed by anotherone or more of the devices of environment 900. Devices of environment900 may interconnect with each other and/or other devices via wiredconnections, wireless connections, or a combination of wired andwireless connections. In some implementations, one or more devices ofenvironment 900 may be physically integrated in, and/or may bephysically attached to, one or more other devices of environment 900.

UE 901 may include a computation and communication device, such as awireless mobile communication device that is capable of communicatingwith RAN 910, RAN 912, and/or DN 950. UE 901 may be, or may include, aradiotelephone, a personal communications system (“PCS”) terminal (e.g.,a device that combines a cellular radiotelephone with data processingand data communications capabilities), a personal digital assistant(“PDA”) (e.g., a device that may include a radiotelephone, a pager,Internet/intranet access, etc.), a smart phone, a laptop computer, atablet computer, a camera, a personal gaming system, an Internet ofThings (“IoT”) device (e.g., a sensor, a smart home appliance, awearable device, a Machine-to-Machine (“M2M”) device, or the like), oranother type of mobile computation and communication device. UE 901 maysend traffic to and/or receive traffic (e.g., user plane traffic) fromDN 950 via RAN 910, RAN 912, and/or UPF/PGW-U 935. In some embodiments,nodes 101, LMS 103, and/or one or more other devices or systemsdiscussed herein may be, may include, or may be implemented by one ormore UEs 901.

RAN 910 may be, or may include, a 5G RAN that includes one or more basestations (e.g., one or more gNBs 911), via which UE 901 may communicatewith one or more other elements of environment 900. UE 901 maycommunicate with RAN 910 via an air interface (e.g., as provided by gNB911). For instance, RAN 910 may receive traffic (e.g., voice calltraffic, data traffic, messaging traffic, signaling traffic, etc.) fromUE 901 via the air interface, and may communicate the traffic toUPF/PGW-U 935, and/or one or more other devices or networks. Similarly,RAN 910 may receive traffic intended for UE 901 (e.g., from UPF/PGW-U935, AMF 915, and/or one or more other devices or networks) and maycommunicate the traffic to UE 901 via the air interface.

RAN 912 may be, or may include, a LTE RAN that includes one or more basestations (e.g., one or more eNBs 913), via which UE 901 may communicatewith one or more other elements of environment 900. UE 901 maycommunicate with RAN 912 via an air interface (e.g., as provided by eNB913). For instance, RAN 910 may receive traffic (e.g., voice calltraffic, data traffic, messaging traffic, signaling traffic, etc.) fromUE 901 via the air interface, and may communicate the traffic toUPF/PGW-U 935, and/or one or more other devices or networks. Similarly,RAN 910 may receive traffic intended for UE 901 (e.g., from UPF/PGW-U935, SGW 917, and/or one or more other devices or networks) and maycommunicate the traffic to UE 901 via the air interface.

AMF 915 may include one or more devices, systems, Virtualized NetworkFunctions (“VNFs”), Cloud-Native Network Functions (“CNFs”), etc., thatperform operations to register UE 901 with the 5G network, to establishbearer channels associated with a session with UE 901, to hand off UE901 from the 5G network to another network, to hand off UE 901 from theother network to the 5G network, manage mobility of UE 901 between RANs910 and/or gNBs 911, and/or to perform other operations. In someembodiments, the 5G network may include multiple AMFs 915, whichcommunicate with each other via the N14 interface (denoted in FIG. 9 bythe line marked “N14” originating and terminating at AMF 915).

MME 916 may include one or more devices, systems, VNFs, CNFs, etc., thatperform operations to register UE 901 with the EPC, to establish bearerchannels associated with a session with UE 901, to hand off UE 901 fromthe EPC to another network, to hand off UE 901 from another network tothe EPC, manage mobility of UE 901 between RANs 912 and/or eNBs 913,and/or to perform other operations.

SGW 917 may include one or more devices, systems, VNFs, CNFs, etc., thataggregate traffic received from one or more eNBs 913 and send theaggregated traffic to an external network or device via UPF/PGW-U 935.Additionally, SGW 917 may aggregate traffic received from one or moreUPF/PGW-Us 935 and may send the aggregated traffic to one or more eNBs913. SGW 917 may operate as an anchor for the user plane duringinter-eNB handovers and as an anchor for mobility between differenttelecommunication networks or RANs (e.g., RANs 910 and 912).

SMF/PGW-C 920 may include one or more devices, systems, VNFs, CNFs,etc., that gather, process, store, and/or provide information in amanner described herein. SMF/PGW-C 920 may, for example, facilitate theestablishment of communication sessions on behalf of UE 901. In someembodiments, the establishment of communications sessions may beperformed in accordance with one or more policies provided by PCF/PCRF925.

PCF/PCRF 925 may include one or more devices, systems, VNFs, CNFs, etc.,that aggregate information to and from the 5G network and/or othersources. PCF/PCRF 925 may receive information regarding policies and/orsubscriptions from one or more sources, such as subscriber databasesand/or from one or more users (such as, for example, an administratorassociated with PCF/PCRF 925).

AF 930 may include one or more devices, systems, VNFs, CNFs, etc., thatreceive, store, and/or provide information that may be used indetermining parameters (e.g., quality of service parameters, chargingparameters, or the like) for certain applications.

UPF/PGW-U 935 may include one or more devices, systems, VNFs, CNFs,etc., that receive, store, and/or provide data (e.g., user plane data).For example, UPF/PGW-U 935 may receive user plane data (e.g., voice calltraffic, data traffic, etc.), destined for UE 901, from DN 950, and mayforward the user plane data toward UE 901 (e.g., via RAN 910, SMF/PGW-C920, and/or one or more other devices). In some embodiments, multipleUPFs 935 may be deployed (e.g., in different geographical locations),and the delivery of content to UE 901 may be coordinated via the N9interface (e.g., as denoted in FIG. 9 by the line marked “N9”originating and terminating at UPF/PGW-U 935). Similarly, UPF/PGW-U 935may receive traffic from UE 901 (e.g., via RAN 910, SMF/PGW-C 920,and/or one or more other devices), and may forward the traffic toward DN950. In some embodiments, UPF/PGW-U 935 may communicate (e.g., via theN4 interface) with SMF/PGW-C 920, regarding user plane data processed byUPF/PGW-U 935.

HSS/UDM 940 and AUSF 945 may include one or more devices, systems, VNFs,CNFs, etc., that manage, update, and/or store, in one or more memorydevices associated with AUSF 945 and/or HSS/UDM 940, profile informationassociated with a subscriber. AUSF 945 and/or HSS/UDM 940 may performauthentication, authorization, and/or accounting operations associatedwith the subscriber and/or a communication session with UE 901.

DN 950 may include one or more wired and/or wireless networks. Forexample, DN 950 may include an Internet Protocol (“IP”)-based PDN, awide area network (“WAN”) such as the Internet, a private enterprisenetwork, and/or one or more other networks. UE 901 may communicate,through DN 950, with data servers, other UEs 901, and/or to otherservers or applications that are coupled to DN 950. DN 950 may beconnected to one or more other networks, such as a public switchedtelephone network (“PSTN”), a public land mobile network (“PLMN”),and/or another network. DN 950 may be connected to one or more devices,such as content providers, applications, web servers, and/or otherdevices, with which UE 901 may communicate.

FIG. 10 illustrates an example Distributed Unit (“DU”) network 1000,which may be included in and/or implemented by one or more RANs (e.g.,RAN 910, RAN 912, or some other RAN). In some embodiments, a particularRAN may include one DU network 1000. In some embodiments, a particularRAN may include multiple DU networks 1000. In some embodiments, DUnetwork 1000 may correspond to a particular gNB 911 of a 5G RAN (e.g.,RAN 910). In some embodiments, DU network 1000 may correspond tomultiple gNBs 911. In some embodiments, DU network 1000 may correspondto one or more other types of base stations of one or more other typesof RANs. As shown, DU network 1000 may include Central Unit (“CU”) 1005,one or more Distributed Units (“DUs”) 1003-1 through 1003-N (referred toindividually as “DU 1003,” or collectively as “DUs 1003”), and one ormore Radio Units (“RUs”) 1001-1 through 1001-M (referred to individuallyas “RU 1001,” or collectively as “RUs 1001”).

CU 1005 may communicate with a core of a wireless network (e.g., maycommunicate with one or more of the devices or systems described abovewith respect to FIG. 9 , such as AMF 915 and/or UPF/PGW-U 935). In theuplink direction (e.g., for traffic from UEs 901 to a core network), CU1005 may aggregate traffic from DUs 1003, and forward the aggregatedtraffic to the core network. In some embodiments, CU 1005 may receivetraffic according to a given protocol (e.g., Radio Link Control (“RLC”))from DUs 1003, and may perform higher-layer processing (e.g., mayaggregate/process RLC packets and generate Packet Data ConvergenceProtocol (“PDCP”) packets based on the RLC packets) on the trafficreceived from DUs 1003.

In accordance with some embodiments, CU 1005 may receive downlinktraffic (e.g., traffic from the core network) for a particular UE 901,and may determine which DU(s) 1003 should receive the downlink traffic.DU 1003 may include one or more devices that transmit traffic between acore network (e.g., via CU 1005) and UE 901 (e.g., via a respective RU1001). DU 1003 may, for example, receive traffic from RU 1001 at a firstlayer (e.g., physical (“PHY”) layer traffic, or lower PHY layertraffic), and may process/aggregate the traffic to a second layer (e.g.,upper PHY and/or RLC). DU 1003 may receive traffic from CU 1005 at thesecond layer, may process the traffic to the first layer, and providethe processed traffic to a respective RU 1001 for transmission to UE901.

RU 1001 may include hardware circuitry (e.g., one or more RFtransceivers, antennas, radios, and/or other suitable hardware) tocommunicate wirelessly (e.g., via an RF interface) with one or more UEs901, one or more other DUs 1003 (e.g., via RUs 1001 associated with DUs1003), and/or any other suitable type of device. In the uplinkdirection, RU 1001 may receive traffic from UE 901 and/or another DU1003 via the RF interface and may provide the traffic to DU 1003. In thedownlink direction, RU 1001 may receive traffic from DU 1003, and mayprovide the traffic to UE 901 and/or another DU 1003.

RUs 1001 may, in some embodiments, be communicatively coupled to one ormore Multi-Access/Mobile Edge Computing (“MEC”) devices, referred tosometimes herein simply as “MECs” 1007. For example, RU 1001-1 may becommunicatively coupled to MEC 1007-1, RU 1001-M may be communicativelycoupled to MEC 1007-M, DU 1003-1 may be communicatively coupled to MEC1007-2, DU 1003-N may be communicatively coupled to MEC 1007-N, CU 1005may be communicatively coupled to MEC 1007-3, and so on. MECs 1007 mayinclude hardware resources (e.g., configurable or provisionable hardwareresources) that may be configured to provide services and/or otherwiseprocess traffic to and/or from UE 901, via a respective RU 1001.

For example, RU 1001-1 may route some traffic, from UE 901, to MEC1007-1 instead of to a core network (e.g., via DU 1003 and CU 1005). MEC1007-1 may process the traffic, perform one or more computations basedon the received traffic, and may provide traffic to UE 901 via RU1001-1. In this manner, ultra-low latency services may be provided to UE901, as traffic does not need to traverse DU 1003, CU 1005, and anintervening backhaul network between DU network 1000 and the corenetwork. In some embodiments, MEC 1007 may include, and/or mayimplement, some or all of the functionality described above with respectto nodes 101, LMS 103, UPF 935, and/or one or more other devices,systems, VNFs, CNFs, etc.

FIG. 11 illustrates example components of device 1100. One or more ofthe devices described above may include one or more devices 1100. Device1100 may include bus 1110, processor 1120, memory 1130, input component1140, output component 1150, and communication interface 1160. Inanother implementation, device 1100 may include additional, fewer,different, or differently arranged components.

Bus 1110 may include one or more communication paths that permitcommunication among the components of device 1100. Processor 1120 mayinclude a processor, microprocessor, or processing logic that mayinterpret and execute instructions. In some embodiments, processor 1120may be or may include one or more hardware processors. Memory 1130 mayinclude any type of dynamic storage device that may store informationand instructions for execution by processor 1120, and/or any type ofnon-volatile storage device that may store information for use byprocessor 1120.

Input component 1140 may include a mechanism that permits an operator toinput information to device 1100 and/or other receives or detects inputfrom a source external to 1140, such as a touchpad, a touchscreen, akeyboard, a keypad, a button, a switch, a microphone or other audioinput component, etc. In some embodiments, input component 1140 mayinclude, or may be communicatively coupled to, one or more sensors, suchas a motion sensor (e.g., which may be or may include a gyroscope,accelerometer, or the like), a location sensor (e.g., a GlobalPositioning System (“GPS”)-based location sensor or some other suitabletype of location sensor or location determination component), athermometer, a barometer, and/or some other type of sensor. Outputcomponent 1150 may include a mechanism that outputs information to theoperator, such as a display, a speaker, one or more light emittingdiodes (“LEDs”), etc.

Communication interface 1160 may include any transceiver-like mechanismthat enables device 1100 to communicate with other devices and/orsystems. For example, communication interface 1160 may include anEthernet interface, an optical interface, a coaxial interface, or thelike. Communication interface 1160 may include a wireless communicationdevice, such as an infrared (“IR”) receiver, a Bluetooth® radio, or thelike. The wireless communication device may be coupled to an externaldevice, such as a remote control, a wireless keyboard, a mobiletelephone, etc. In some embodiments, device 1100 may include more thanone communication interface 1160. For instance, device 1100 may includean optical interface and an Ethernet interface.

Device 1100 may perform certain operations relating to one or moreprocesses described above. Device 1100 may perform these operations inresponse to processor 1120 executing software instructions stored in acomputer-readable medium, such as memory 1130. A computer-readablemedium may be defined as a non-transitory memory device. A memory devicemay include space within a single physical memory device or spreadacross multiple physical memory devices. The software instructions maybe read into memory 1130 from another computer-readable medium or fromanother device. The software instructions stored in memory 1130 maycause processor 1120 to perform processes described herein.Alternatively, hardwired circuitry may be used in place of or incombination with software instructions to implement processes describedherein. Thus, implementations described herein are not limited to anyspecific combination of hardware circuitry and software.

The foregoing description of implementations provides illustration anddescription, but is not intended to be exhaustive or to limit thepossible implementations to the precise form disclosed. Modificationsand variations are possible in light of the above disclosure or may beacquired from practice of the implementations.

For example, while series of blocks and/or signals have been describedabove (e.g., with regard to FIGS. 1-8 ), the order of the blocks and/orsignals may be modified in other implementations. Further, non-dependentblocks and/or signals may be performed in parallel. Additionally, whilethe figures have been described in the context of particular devicesperforming particular acts, in practice, one or more other devices mayperform some or all of these acts in lieu of, or in addition to, theabove-mentioned devices.

The actual software code or specialized control hardware used toimplement an embodiment is not limiting of the embodiment. Thus, theoperation and behavior of the embodiment has been described withoutreference to the specific software code, it being understood thatsoftware and control hardware may be designed based on the descriptionherein.

In the preceding specification, various example embodiments have beendescribed with reference to the accompanying drawings. It will, however,be evident that various modifications and changes may be made thereto,and additional embodiments may be implemented, without departing fromthe broader scope of the invention as set forth in the claims thatfollow. The specification and drawings are accordingly to be regarded inan illustrative rather than restrictive sense.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of the possible implementations. Infact, many of these features may be combined in ways not specificallyrecited in the claims and/or disclosed in the specification. Althougheach dependent claim listed below may directly depend on only one otherclaim, the disclosure of the possible implementations includes eachdependent claim in combination with every other claim in the claim set.

Further, while certain connections or devices are shown, in practice,additional, fewer, or different, connections or devices may be used.Furthermore, while various devices and networks are shown separately, inpractice, the functionality of multiple devices may be performed by asingle device, or the functionality of one device may be performed bymultiple devices. Further, multiple ones of the illustrated networks maybe included in a single network, or a particular network may includemultiple networks. Further, while some devices are shown ascommunicating with a network, some such devices may be incorporated, inwhole or in part, as a part of the network.

To the extent the aforementioned implementations collect, store, oremploy personal information of individuals, groups or other entities, itshould be understood that such information shall be used in accordancewith all applicable laws concerning protection of personal information.Additionally, the collection, storage, and use of such information canbe subject to consent of the individual to such activity, for example,through well known “opt-in” or “opt-out” processes as can be appropriatefor the situation and type of information. Storage and use of personalinformation can be in an appropriately secure manner reflective of thetype of information, for example, through various access control,encryption and anonymization techniques for particularly sensitiveinformation.

No element, act, or instruction used in the present application shouldbe construed as critical or essential unless explicitly described assuch. An instance of the use of the term “and,” as used herein, does notnecessarily preclude the interpretation that the phrase “and/or” wasintended in that instance. Similarly, an instance of the use of the term“or,” as used herein, does not necessarily preclude the interpretationthat the phrase “and/or” was intended in that instance. Also, as usedherein, the article “a” is intended to include one or more items, andmay be used interchangeably with the phrase “one or more.” Where onlyone item is intended, the terms “one,” “single,” “only,” or similarlanguage is used. Further, the phrase “based on” is intended to mean“based, at least in part, on” unless explicitly stated otherwise.

1. A device, comprising: one or more processors configured to: generatea group of distributed ledgers that are each associated with arespective set of ledger parameters, wherein the group of distributedledgers includes: a first distributed ledger that is associated with afirst set of ledger parameters, and a second distributed ledger that isassociated with a second set of ledger parameters; receive a data itemthat is associated with a particular set of attributes; identify thatthe particular set of attributes of the data item meet the first set ofledger parameters and the second set of ledger parameters; record thedata item to the first and second distributed ledgers based onidentifying that the particular set of attributes of the data item meetthe first and second sets of ledger parameters; determine, afterrecording the data item to the first and second distributed ledgers,that a set of archival parameters, associated with the first distributedledger, have been met; and remove the first distributed ledger from thegroup of distributed ledgers based on determining that the set ofarchival parameters, associated with the first distributed ledger, havebeen met, wherein the data item is retained in the second distributedledger after the first distributed ledger is removed.
 2. The device ofclaim 1, wherein the group of distributed ledgers is maintained by aplurality of nodes, wherein removing the first distributed ledger fromthe group of distributed ledgers includes notifying the plurality ofnodes that the first ledger has been removed.
 3. The device of claim 2,wherein the plurality of nodes maintain a set of ledger data associatedwith the group of distributed ledgers, wherein the plurality of nodeserase particular ledger data, associated with maintaining the firstdistributed ledger, based on receiving a notification that the firstdistributed ledger has been removed.
 4. The device of claim 1, whereinthe set of ledger parameters associated with the first distributedledger includes temporal parameters, wherein the set of archivalparameters associated with the first distributed ledger include one ormore temporal conditions, and wherein determining that the set ofarchival parameters, associated with the first distributed ledger havebeen met includes determining that the temporal parameters associatedwith the first distributed ledger meet the one or more temporalconditions.
 5. The device of claim 4, wherein the temporal parametersinclude a first time window, wherein the set of archival parametersinclude a second time window that is associated with data to be removedfrom the first distributed ledger, and wherein determining that thetemporal parameters associated with the first distributed ledger meetthe one or more temporal conditions includes determining that the firsttime window is within the second time window.
 6. The device of claim 1,wherein the set of archival parameters associated with the firstdistributed ledger include a first time indicating staleness of data,and wherein determining that the set of archival parameters, associatedwith the first distributed ledger, have been met includes determiningthat ledger parameters associated with the first distributed ledgerindicate that the first distributed ledger is associated with a secondtime that precedes the first time.
 7. The device of claim 1, wherein theone or more processors are further configured to: receive a query;determine that one or more attributes of the query match one or moreledger parameters associated with the first distributed ledger that hasbeen removed; and without performing a search on the other distributedledgers of the group of distributed ledgers, provide a response to thequery indicating that a result for the query was not found.
 8. Anon-transitory computer-readable medium, storing a plurality ofprocessor-executable instructions to: generate a group of distributedledgers that are each associated with a respective set of ledgerparameters, wherein the group of distributed ledgers includes: a firstdistributed ledger that is associated with a first set of ledgerparameters, and a second distributed ledger that is associated with asecond set of ledger parameters; receive a data item that is associatedwith a particular set of attributes; identify that the particular set ofattributes of the data item meet the first set of ledger parameters andthe second set of ledger parameters; record the data item to the firstand second distributed ledgers based on identifying that the particularset of attributes of the data item meet the first and second sets ofledger parameters; determine, after recording the data item to the firstand second distributed ledgers, that a set of archival parameters,associated with the first distributed ledger, have been met; and removethe first distributed ledger from the group of distributed ledgers basedon determining that the set of archival parameters, associated with thefirst distributed ledger, have been met, wherein the data item isretained in the second distributed ledger after the first distributedledger is removed.
 9. The non-transitory computer-readable medium ofclaim 8, wherein the group of distributed ledgers is maintained by aplurality of nodes, wherein removing the first distributed ledger fromthe group of distributed ledgers includes notifying the plurality ofnodes that the first ledger has been removed.
 10. The non-transitorycomputer-readable medium of claim 9, wherein the plurality of nodesmaintain a set of ledger data associated with the group of distributedledgers, wherein the plurality of nodes erase particular ledger data,associated with maintaining the first distributed ledger, based onreceiving a notification that the first distributed ledger has beenremoved.
 11. The non-transitory computer-readable medium of claim 8,wherein the set of ledger parameters associated with the firstdistributed ledger includes temporal parameters, wherein the set ofarchival parameters associated with the first distributed ledger includeone or more temporal conditions, and wherein determining that the set ofarchival parameters, associated with the first distributed ledger havebeen met includes determining that the temporal parameters associatedwith the first distributed ledger meet the one or more temporalconditions.
 12. The non-transitory computer-readable medium of claim 11,wherein the temporal parameters include a first time window, wherein theset of archival parameters include a second time window that isassociated with data to be removed from the first distributed ledger,and wherein determining that the temporal parameters associated with thefirst distributed ledger meet the one or more temporal conditionsincludes determining that the first time window is within the secondtime window.
 13. The non-transitory computer-readable medium of claim 8,wherein the set of archival parameters associated with the firstdistributed ledger include a first time indicating staleness of data,and wherein determining that the set of archival parameters, associatedwith the first distributed ledger, have been met includes determiningthat ledger parameters associated with the first distributed ledgerindicate that the first distributed ledger is associated with a secondtime that precedes the first time.
 14. The non-transitorycomputer-readable medium of claim 8, wherein the processor-executableinstructions further include processor-executable instructions to:receive a query; determine that one or more attributes of the querymatch one or more ledger parameters associated with the firstdistributed ledger that has been removed; and without performing asearch on the other distributed ledgers of the group of distributedledgers, provide a response to the query indicating that a result forthe query was not found.
 15. A method, comprising: generating a group ofdistributed ledgers that are each associated with a respective set ofledger parameters, wherein the group of distributed ledgers includes: afirst distributed ledger that is associated with a first set of ledgerparameters, and a second distributed ledger that is associated with asecond set of ledger parameters; receiving a data item that isassociated with a particular set of attributes; identifying that theparticular set of attributes of the data item meet the first set ofledger parameters and the second set of ledger parameters; recording thedata item to the first and second distributed ledgers based onidentifying that the particular set of attributes of the data item meetthe first and second sets of ledger parameters; determining, afterrecording the data item to the first and second distributed ledgers,that a set of archival parameters, associated with the first distributedledger, have been met; and removing the first distributed ledger fromthe group of distributed ledgers based on determining that the set ofarchival parameters, associated with the first distributed ledger, havebeen met, wherein the data item is retained in the second distributedledger after the first distributed ledger is removed.
 16. The method ofclaim 15, wherein the group of distributed ledgers is maintained by aplurality of nodes, wherein removing the first distributed ledger fromthe group of distributed ledgers includes notifying the plurality ofnodes that the distributed ledger has been removed.
 17. The method ofclaim 16, wherein the plurality of nodes maintain a set of ledger dataassociated with the group of distributed ledgers, wherein the pluralityof nodes erase particular ledger data, associated with maintaining thefirst distributed ledger, based on receiving a notification that thefirst distributed ledger has been removed.
 18. The method of claim 15,wherein the set of ledger parameters associated with the firstdistributed ledger includes temporal parameters that include a firsttime window, wherein the set of archival parameters associated with thefirst distributed ledger include one or more temporal conditions thatinclude a second time window that is associated with data to be removedfrom the first distributed ledger, wherein determining that the set ofarchival parameters, associated with the first distributed ledger havebeen met includes determining that the temporal parameters associatedwith the first distributed ledger meet the one or more temporalconditions, and wherein determining that the temporal parametersassociated with the first distributed ledger meet the one or moretemporal conditions includes determining that the first time window iswithin the second time window.
 19. The method of claim 15, wherein theset of archival parameters associated with the first distributed ledgerinclude a first time indicating staleness of data, and whereindetermining that the set of archival parameters, associated with thefirst distributed ledger, have been met includes determining that ledgerparameters associated with the first distributed ledger indicate thatthe first distributed ledger is associated with a second time thatprecedes the first time.
 20. The method of claim 15, further comprising:receiving a query; determining that one or more attributes of the querymatch one or more ledger parameters associated with the firstdistributed ledger that has been removed; and without performing asearch on the other distributed ledgers of the group of distributedledgers, providing a response to the query indicating that a result forthe query was not found.